Does anybody know if there is an upper limit to the number of objects that can be created in a single module, and if so what impact does approaching this limit have on performance? I have just imported 54,000 objects (with 10 text attributes per object) and it is taking 30 minutes (!) to save a simple change to the module. Right now the module is plain vanilla with no heirarchy, no links and no dxl. I have no idea if this is a client, server or application issue.
For those interested I was intending to link the 54,000 "problem" tracking objects to the Test Results and to the source Requirements, but if performance is going to be an issue I may have to rethink.
SystemAdmin - Wed Jun 24 12:04:25 EDT 2009 |
|
Re: Object limit in a Module
IBM_Gust - Wed Jun 24 13:33:44 EDT 2009
I believe you have already answered yourself.
|
|
Re: Object limit in a Module
kbmurphy - Wed Jun 24 13:44:41 EDT 2009 IBM_Gust - Wed Jun 24 13:33:44 EDT 2009
I believe you have already answered yourself.
What you need to do is baseline. Get rid of that object history. Then make your change and it should go faster.
Also, be sure you're connected to a local server (not VPN)...any network hiccups and you're a goner.
|
|
Re: Object limit in a Module
Tony_Goodman - Thu Jun 25 02:56:19 EDT 2009
Hi Graham,
There is no upper limit, but DOORS has an annoying habit of saving the whole module, even if you make a single change. That's a lot of information being sent back to the server. I have addressed this issue in the past by using lockable sections, that way DOORS only saves the section(s) you are saving and thus improves performance.
|
|
Re: Object limit in a Module
SystemAdmin - Thu Jun 25 06:20:20 EDT 2009 kbmurphy - Wed Jun 24 13:44:41 EDT 2009
I don't believe there is an object limit in a module. I've worked with modules with 50000+ objects in them.
What you need to do is baseline. Get rid of that object history. Then make your change and it should go faster.
Also, be sure you're connected to a local server (not VPN)...any network hiccups and you're a goner.
I am connected directly to the server via a 100MB LAN, and looking at task manager there is not much network traffic - just lots of waiting. Maybe I need to get our network guys to look at the problem.
|
|
Re: Object limit in a Module
SystemAdmin - Thu Jun 25 06:42:13 EDT 2009 Tony_Goodman - Thu Jun 25 02:56:19 EDT 2009
Hi Graham,
There is no upper limit, but DOORS has an annoying habit of saving the whole module, even if you make a single change. That's a lot of information being sent back to the server. I have addressed this issue in the past by using lockable sections, that way DOORS only saves the section(s) you are saving and thus improves performance.
Thanks for your reply and good to hear from you again. I was guessing that DOORS was saving the whole module even for a single change - not really very clever. As mentioned in my reply to one of the other respondents this is a new module with no history etc, so I am thinking either I have hit a DOORS performance limitation or I have network/server connectivity problem which is not obvious with my other (much smaller) modules. At present the 30 minute save time is simple unworkable. I could try lockable sections as you suggest but I think there is a perfomance limit on those also if you have too many sections beyond about 3 or 4?? Probably a better way is to create a second module to hold the old (archieved) objects and keep only work-in-progress objects in the existing module. That way the recent stuff is readily workable/accessible but less frequently needed stuff takes longer to update although clearly this approach will impact searching and filtering.
As you will probably know, we are running 8.1 and Windows XP but moving to 9 soon. Do you think I can expect any improvement with the later version?
|
|
Re: Object limit in a Module
mcnairk - Thu Jun 25 08:29:32 EDT 2009 SystemAdmin - Thu Jun 25 06:42:13 EDT 2009
Hi Tony
Thanks for your reply and good to hear from you again. I was guessing that DOORS was saving the whole module even for a single change - not really very clever. As mentioned in my reply to one of the other respondents this is a new module with no history etc, so I am thinking either I have hit a DOORS performance limitation or I have network/server connectivity problem which is not obvious with my other (much smaller) modules. At present the 30 minute save time is simple unworkable. I could try lockable sections as you suggest but I think there is a perfomance limit on those also if you have too many sections beyond about 3 or 4?? Probably a better way is to create a second module to hold the old (archieved) objects and keep only work-in-progress objects in the existing module. That way the recent stuff is readily workable/accessible but less frequently needed stuff takes longer to update although clearly this approach will impact searching and filtering.
As you will probably know, we are running 8.1 and Windows XP but moving to 9 soon. Do you think I can expect any improvement with the later version?
-
I'm not sure shared edit will improve performance; in my experience, it usually slows things down.
-
Migrating to DOORS 9 will probabaly not improve performance.
How much horsepower does your server have? Perhaps you need more memory...
Ken.
|
|
Re: Object limit in a Module
L_Gunderson - Thu Jun 25 11:30:43 EDT 2009
We have 5 Users entering information into the same modules. We use the shareable edit and section locks to make this work. We have 50 or more lockable sections in each module and the largest module has 10,000-15,000 rows with 25 columns. They might be a little slow opening, but it is all we have known.
Our Test Cases module has numerous rows with as many as 2,500 links each. Since we use the section locks, each save is quick. If anyone opens any of the modules exclusivly then saves, it still takes less than 1 minute. Opening the Properties screen is slower than the save.
So... I'm thinking that you may have a server or commuication issue rather than a Doors issue.
Hope this helps.
|
|
Re: Object limit in a Module
mcnairk - Thu Jun 25 15:10:07 EDT 2009 mcnairk - Thu Jun 25 08:29:32 EDT 2009
I don't know what your problem is but:
-
I'm not sure shared edit will improve performance; in my experience, it usually slows things down.
-
Migrating to DOORS 9 will probabaly not improve performance.
How much horsepower does your server have? Perhaps you need more memory...
Ken.
Joined Telelogic DOORS forum 12-Sep-2003.
DOORS 8.2, running on Windows 2000 Server, accessed via Citrix.
|
|
Re: Object limit in a Module
mcnairk - Thu Jun 25 15:14:01 EDT 2009 mcnairk - Thu Jun 25 15:10:07 EDT 2009
Just for curiosity, I tried this out for myself: 60k objects with text only
Joined Telelogic DOORS forum 12-Sep-2003.
DOORS 8.2, running on Windows 2000 Server, accessed via Citrix.
I tried this out for myself in DOORS 8.2 with 60k objects with text only (no OLE) in the object text and 10 text attributes with no links or shared edit. It takes about 30 seconds to save a change to a single object. I think you have a problem specific to your database.
Have you reported this to IBM?
Ken.
|
|
Re: Object limit in a Module
SystemAdmin - Mon Jun 29 05:47:03 EDT 2009 mcnairk - Thu Jun 25 15:14:01 EDT 2009
OK, that last posting got sent prematurely, it should have read:
I tried this out for myself in DOORS 8.2 with 60k objects with text only (no OLE) in the object text and 10 text attributes with no links or shared edit. It takes about 30 seconds to save a change to a single object. I think you have a problem specific to your database.
Have you reported this to IBM?
Ken.
You have demonstrated that the DOORS application can handle more objects than I have got and 30 secs for a save is quite acceptable (by comparision with the 30 mins!! it takes me). My problem must be with the client/server or comms and not with the DOORS app. I have got our network folk looking at the problem but I think we may need to involve IBM also.
Thanks again for your tests - I will report back when we assertain the root cause of the problem.
Graham
|
|
Re: Object limit in a Module
SystemAdmin - Mon Jun 29 06:15:03 EDT 2009 L_Gunderson - Thu Jun 25 11:30:43 EDT 2009
We have 5 Users entering information into the same modules. We use the shareable edit and section locks to make this work. We have 50 or more lockable sections in each module and the largest module has 10,000-15,000 rows with 25 columns. They might be a little slow opening, but it is all we have known.
Our Test Cases module has numerous rows with as many as 2,500 links each. Since we use the section locks, each save is quick. If anyone opens any of the modules exclusivly then saves, it still takes less than 1 minute. Opening the Properties screen is slower than the save.
So... I'm thinking that you may have a server or commuication issue rather than a Doors issue.
Hope this helps.
However as you say, I have come to the conclusion that my problems is indeed client/server or network related rather than a DOORS app issue. Ken (see next post) has done a test with a very similar setup to me and he does not have a problem. So I've got our IT folk looking at my problem and will report back when we have it fixed.
Thanks for your interest, and I hope this thread is useful to others.
Graham
|
|
Re: Object limit in a Module
llandale - Mon Jun 29 12:56:12 EDT 2009
You can use a DOS Command Prompt window to 'ping' your DOORS server from your client. Your IT folks will understand that. IIRC, 30ms ping time is the about the boundary between 'tolerable' and 'intolerable'; but perhaps others have opinions on that.
|
|
Re: Object limit in a Module
SystemAdmin - Fri Jul 03 06:23:44 EDT 2009 llandale - Mon Jun 29 12:56:12 EDT 2009
You can use a DOS Command Prompt window to 'ping' your DOORS server from your client. Your IT folks will understand that. IIRC, 30ms ping time is the about the boundary between 'tolerable' and 'intolerable'; but perhaps others have opinions on that.
regards
Graham
|
|
Re: Object limit in a Module
MikeGehringer - Tue Jul 07 17:32:38 EDT 2009 SystemAdmin - Fri Jul 03 06:23:44 EDT 2009
Already tried that - response was less than 1ms!
regards
Graham
Just a few other thoughts...
-
do any of the objects have OLE inserted in them?
-
none of the attributes are DXL attributes?
-
what about links? Are there any? how many link modules do you use?
Have you considered re-architecting the module? Perhaps break it up into smaller modules based on your schema...
I notice that adding a few OLE elements causing a considerable slowdown even when brought in as a icon, seems like it is trying to bring in the whole OLE instead of a just a representation or pointer for it.
Mike G>
|
|
Re: Object limit in a Module
SystemAdmin - Thu Jul 09 03:26:01 EDT 2009 MikeGehringer - Tue Jul 07 17:32:38 EDT 2009
Graham,
Just a few other thoughts...
-
do any of the objects have OLE inserted in them?
-
none of the attributes are DXL attributes?
-
what about links? Are there any? how many link modules do you use?
Have you considered re-architecting the module? Perhaps break it up into smaller modules based on your schema...
I notice that adding a few OLE elements causing a considerable slowdown even when brought in as a icon, seems like it is trying to bring in the whole OLE instead of a just a representation or pointer for it.
Mike G>
Don't use Text attributes where a String will do and you should see some performance improvement.
Text = Return Carriages and no limit to length
String = No return carriages and max length 968 chars (or 468 - I can't remeber)
|
|